Contact server for call center

ABSTRACT

The present invention is a Contact Server that enables customers to submit call-back requests to a call center via the Internet, or virtually any other communications technology available. A call-back to the customer can be placed via any communications technology available. In its preferred embodiment, the Contact Server enables a call-back request to be submitted by a customer directly from an HTML page on a Web site, and have that same HTML page be presented to the agent that receives the call-back request. The agent can then place a telephone call to the number provided by the customer who submitted the call-back request, and at the same time, establish a TCP/IP communications session with the customer. This TCP/IP session can proceed between the agent&#39;s Web browser and the customer&#39;s Web browser, and the visible actions performed by the agent are transferred to the customer and displayed on the customer&#39;s browser. The TCP/IP session proceeds simultaneous with the telephone call between the agent and the customer.

This application is a continuation of U.S. patent application Ser. No.09/417,327, filed on Oct. 13, 1999, which is now U.S. Pat. No.6,654,815, which is a divisional of U.S. patent application Ser. No.08/976,162, filed on Nov. 21, 1997, which is now U.S. Pat. No.6,493,447. Both applications 09/417,327 and 08/976,162 are herebyincorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to data communications, and moreparticularly to customer to company call center communications in thetelecommunications industry.

BACKGROUND OF THE INVENTION

In the telecommunications industry, call centers are used to providecustomer and operator services for business clients. Traditionally,customers of these business clients place a phone call to a toll-freetelephone number to reach a call center customer service agent. They arethen served over the phone. Often, because of the limited number ofagents at a call center and the large number of calls, a customer's callis placed in a queue until an agent becomes available.

Many customers in the telecommunications industry interact with theInternet and World Wide Web, and use the Web for a variety of businessservices. This presents a business opportunity to interact withcustomers who are familiar with browsing the Web, by presenting to thecustomer a Web site and an opportunity to interact with thetelecommunications company. However, the World Wide Web is not aninteractive media, and is primarily composed of many static HTML pagesat any given Web site.

The customers browsing the Web site may have a need to speak with acustomer service agent, either with respect to the Web site andinformation posted there, or with respect to their transactions with thetelecommunications company.

Many companies, including telecommunications companies, maintain callcenters to interact with their customers. These call centers may provideorder entry clerks for new orders, billing services for resolvingproblems with invoices, shipments or returns, technical support, andtrouble ticketing for customers having a high volume of transactionswith the company.

However, given the volume of customer calls, and the company resourcesavailable to response to the calls, most calls to the call center areplaced on-hold by an ACD (automatic call director), and the initialcustomer interaction is with an IVR (interactive voice response) unit,which is primarily intended to direct the call to the proper agent, andis not programmed to answer a customer's questions. This frequentlyleads to aggravated customers who are unable to resolve their concernsin a timely manner.

The only means presently available to contact a company call centeragent and not be placed on hold, is to place a telephone call and submita call-back request via the telephone, or to send an e-mail request tothe “web master” of the Web site. Current Web services do not allowcall-back requests to be submitted via the Web or other Interactivemeans.

SUMMARY OF THE PRESENT INVENTION

The present invention is a Contact Server that enables customers tosubmit call-back requests to a call center via the Internet, orvirtually any other communications technology available. In itspreferred embodiment, the Contact Server enables a call-back request tobe submitted by a customer directly from an HTML page on the companies'Web site, and have that same HTML page be presented to an agent whoreceives the call-back request. The Contact Server can immediatelydetermine if an agent is available, and if the agent is available, theagent can then place a telephone call to the number provided by thecustomer who submitted the-call-back request, and at the same time,establish a TCP/IP communications session with the customer. This TCP/IPsession can proceed between the agent's Web browser and the customer'sWeb browser, and the visible actions performed by the agent aretransferred to the customer and displayed on the customer's browser. TheTCP/IP session proceeds simultaneous with the telephone call between theagent and the customer.

If an agent is not available, the Contact Server can be used to providecall-back services at a later time via telephony, the Web, or virtuallyany other communications technology. A call-back request can besubmitted by the agent to the Contact Server to establish communicationwith the customer via data communications over the Internet, voicetelephony over the Internet, video conference over the Internet, orvoice telephony over the PSTN or any other technology available.

It is an object of the present invention to provide a Contact Serverthat manages call-back services for call center agents in a genericmanner, so that any communications network can be used for receivingcall-back requests and placing call-backs to customers.

It is another object of the present invention to provide a first database relating to a customers requirements, resources and entitlements, asecond data base relating to the type of support requested in the HTMLpage in which the call back request is posted, and a third dynamic database of available call center agents and the presently available skilllevels relevant to the requested support.

It is another object of the invention to enable the Contact Server toreserve a qualified agent when it receives a call-back request, based onthe skill level of the agent and the requested support. That agent ispresented with the call-back information submitted by the customer, aswell as the Web page from which the call-back request was placed.

Whether the call back request is satisfied immediately, as for example,when an agent is immediately available to respond to the customersrequest, or whether the call back comes at a later time period, theagent is thus placed in synch with the customer in the context of theircompanies' Web site. Once TCP/IP communications are established betweenthe agent and the customer, the agent can perform visible tasks on theagent's Web browser, and the customer can view these tasks. This occurssimultaneously with their telephony conversations.

It is another object of the present invention to enable establishmentand maintenance of plural TCP/IP communications paths over the Internetbetween an agent and a customer. While the preferred embodiment utilizeshttp and telephony communications, http may be combined with chat orsmtp to provide simultaneous communications between the customer andagent, and if the customer has a desktop with voice telephony or videotelephony, simultaneous communications may proceed with one of thesepaths as well.

The http communications through the Web site may be enabled and enhancedby Java applets that may be stored on the Web Server that provides theWeb site, on the Contact Server, or on a secure data server. These Javaapplets may then be simultaneously downloaded to and executed on theagent's and customer's Web browsers. The present invention also providesmeans to synchronize the execution applets on each desktop to ensurethat the agent and customer may communicate with respect to the samedata.

In a preferred embodiment of the present invention, a data server isprovided to poll a company main frame system to obtain the status oftrouble tickets previously entered and tracked on the main frame system,and to format the main frame data trouble ticket into HTML data fortransmission to the customer via http.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagrammatic illustration of the logical networkarchitecture of a company call center which utilizes the presentinvention, which also illustrates the Contact Server of the presentinvention.

FIG. 2 is a diagrammatic illustration of a physical networkarchitecture, illustrating one possible implementation of the logicalarchitecture-of FIG. 1.

FIG. 3 is a diagrammatic illustration of the Contact Server of thepresent invention and the components of the call center network withwhich it interacts.

FIG. 4 is a diagrammatic illustration of an implementation of thepresent invention which provides security for the companies' data.

FIG. 5 is a logical state diagram of the agent availability logic usedby the Contact Server of the present invention,

FIG. 6 is a representative illustration of a sample HTML web page whichenables a call back request.

FIGS. 7 a, 7 b and 7 c illustrate one possible logical implementation ofthe Contact Server within the company call center of FIG. 1.

FIG. 8 is a diagrammatic illustration of one possible implementation ofthe push/pull synchronization of the agent and customer web browsers.

FIGS. 9( a)(b) and (c) illustrates one possible logical implementationof the push/pull synchronization of the agent and customer web browsers.

FIG. 10 is a diagrammatic illustration of the logical networkarchitecture of a company call center of FIG. 1 which utilizes alternateIP telephony protocols for communication between the agent and thecustomer.

FIG. 11 is a figurative illustration of the network architecture of acompany call center according to FIG. 1 which utilizes multiplealternate TCP/IP Protocols for communication between the agent and thecustomer.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1 is a diagrammatic illustration of the logical networkarchitecture of a company call center which utilizes the presentinvention. The invention may include the standard components of acompany call center such as an Automatic Call Distributor 12 (ACD),which provides a telephony switching means; a plurality of AgentWorkstations, one of which is illustrated in FIG. 1 at 14. The agentwork stations 14 normally include a Personal Computer (PC) runningcustomized communications and browser software and an agent telephonestation. The call center may also include one or more Voice ResponseUnits (VRU), one of which is illustrated in FIG. 1 at 16; and aComputer/Telephony Interface (CTI) Server 18, which provides a datainterface to the ACD for the other components of the invention.

The ACD 12 is linked to the Public Switched Telephone Network 20 (PSTN)via voice trunks 22. All incoming telephony calls to the call centerarrive at the ACD 12. The ACD 12 has voice trunks 24 to each agentworkstation 14 (specifically the telephone station) and to each VRU 16.Agent workstations 14 are operated by live operators to provide customerand operator services. The VRUs 16 run specialized interactive voiceresponse applications for providing automated customer and operatorservices. The CTI port to the ACD is also linked via link 26 to the CTIServer 18. One representative example of a suitable telephony server 18is the T-Server as manufactured by Genesys.

The CTI Server 18 provides event data from the ACD 12 to computers suchas the agent workstations 14, VRUs 16, and the Contact Server 28.

In accordance with the present invention, Contact Server 28 is used toprovide call-back services for customers separate from, in addition toand in conjunction with any call back services provided by the ACD 12and VRUs 16. The Contact Server 28 may also receive call-back requestsdirectly from customers over an IP network from web server 30, and itdistributes requests to qualified agents at agent work stations 14. Thecontact server 28 may also reserve qualified agents for specific typesof problems in order to fulfill the call-back request.

In the preferred embodiment, customers submit call-back requests via theInternet 32, an Intranet or other comparable IP network, and agents mayfulfill those requests by placing outbound calls to the customers viathe ACD 12 and PSTN 20. However, the Contact Server 28 is designed tomanage call-back services in a manner that is independent of thecommunications networks used. As will hereinafter be described ingreater detail, these call back services may include other methods ofreceiving and fulfilling call-back requests such as Internet voicetelphony, Internet video, chat or e-mail communications.

The Contact Server 28 also facilitates communications with other datasources, such as a data base server 34, or other data resources, such asa company main frame, as generally illustrated at 36. These data sourcesinclude components such as database servers 34 that store and serve dataspecific to whatever applications and services are provided by the callcenter. For example, one implementation of the Contact Server andcall-back service is to enhance a service that enables externalcustomers of the company to view any trouble tickets over the Internetor IP network by accessing a trouble ticket database. Alternately, theContact Server may access a company main frame system which providesproblem identification services for customers. These types of resourcesare embodied on a data resource as represented in FIG. 1 by other datasources 36.

In one embodiment of the invention, a Web site may be provided forproviding this service, which site is supported by an Intranet Server 66as illustrated in FIG. 1. In this embodiment, the Intranet Server 66interfaces directly with this database server 34 and other data sources36, as shown in FIG. 1. The intra company interface is generally viadata communications over a LAN or WAN network.

FIG. 2 illustrates one possible implementation of the logicalarchitecture of FIG. 1 in a physical network architecture having anEthernet LAN 38 which provides data connectivity among the variouscomputer components of the call center described with respect to FIG. 1.

Each agent workstation 14 runs a Web browser, such as MicrosoftExplorer® or Netscape Navigator® or Communicator® for IP communications,and customer service workflow software, such as Clarify®, for providingcustomer services.

The database server 34 represents and embodies all databases related tothe call-back service. As will be hereinafter described in greaterdetail, these include a call-back request database in which call-backrequests are stored and queued, agent state tables, and agent skillstables.

The intranet server 66 is a computer that embodies a Web Server 30. TheWeb Server 30 supports the Web site and TCP/IP communications forwhatever services are being supported by the call center, such as theWeb site that allows customers access to a trouble ticket databasemaintained on data base server 34.

A customer, generically illustrated at 42 in FIGS. 1 and 2, who desiresto make use of the invention will normally-have a Personal Computer (PC)44 running customized communications and browser software and atelephone 46.

Java applets may be used in the practice of the invention to support thecall-back service and the applets and other features are stored on andmay be downloaded within the company LAN or WAN from the Web Server 30.A second server, referred to as a Firewall Server 40, provides securedaccess to the Intranet Server 66 from the Internet 32.

The Firewall Server 40 has an identical Web Server process running onit; it is from this Web Server (on the Firewall Server 40) that the Javaapplets are downloaded to the customer PC and web browser 42. IdenticalJava applets are downloaded to agent workstations 14 from the Web Server30 that runs on the Intranet Server 66. The use of the Firewall Server40 will hereinafter be described in greater detail with reference toFIG. 4.

As shown in FIG. 2, the Firewall Server 40 interfaces with the WebServer 30 via the Ethernet LAN 38 and accesses the Internet 32 via oneor more IP Routers 48.

Standard mid-range computers, such as DEC Alpha 4100 or 8400 servers,can be used for the Contact Server 28, Database Server 34, IntranetServer 66, Firewall Server 40, and may also be used for the other datasources 36.

When the Contact Server 28 is first brought on-line, it registers itselfas a client with the CTI Server 18, and requests to receive certainevents. These events generally relate to agent 14 activities, such aslogon, answer call, etc. The Contact Server 28 uses these events tomaintain a state table, which is stored in the Database Server 34. Thestate table tracks the current state of each agent 14. The ContactServer 28 uses this to determine which agents are available to handle acall-back request. In the preferred embodiment, Microsoft's SQL Serveris used for the state tables stored on the Database Server 34.

As a novel advantage of the Contact Server 28, it eliminates the needfor an agent workstation 14 to interface with the CTI Server 18. In FIG.1, the link between the agent workstation 14 and the CTI Server 18 isdesignated optional; this link is used in prior art call centers. But inaccordance with the present invention, she agent workstation 14 has alink and API with the Contact Server 28 to perform the functions. TheContact Server 28 receives events from the agent workstation 14 andupdates its state tables accordingly, thus tracking the state of eachagent. Agents can place outbound calls from their workstations bysubmitting a command to do so to the Contact Server 28. This featuremakes any communications networks used by the call center transparent tothe agent workstation 14, which in turn simplifies both the programmingof agent workstation software applications and agent responsibilities.

In the preferred embodiment of the Contact Server 28 and the call-backservices it provides, a customer uses a PC equipped with a Web browser44 to access a Web site that is supported by the Web Server 30 on thecall center's Intranet Server 66. This Web site is secured and requiresuser authentication. Therefore, a customer must first be setup with auser profile. User profiles may be stored on the Database Server 34, andcontain the customer's user i.d., password, and any other data as neededby the particular service. When the customer 42 has been authenticated,the Web Server 30 sends an HTML file that represents the site's homepage to the customer's browser 44. Embedded in this file are the Javaapplets that manage the call-back services and TCP/IP sessions withagents 14. The Web Server 30 maintains a session with the customer'sbrowser 44, using cookies or other session maintenance methodology.

While browsing the Web site, the customer 42 may encounter a need tospeak with a call center agent. For example, if the Web site providesaccess to the trouble ticket database, a customer 42 may view a statusof their trouble tickets and subsequently have a question. This is wherethe call-back service of the present invention is used. An option toplace a call-back request is presented; this may be as a floating toolbar or an HTML button presented on each page of the Web site. Whenselected, the Java applet running on the customer's browser 44 presentsa dialog box, which prompts the customer for call-back information. Thisgenerally includes the customer's name, call-back telephone number, andperhaps other information as needed. When the customer hits enter, thebrowser sends a message containing this information to the IntranetServer 66, via the Internet 32.

The Intranet Server 66 receives the call-back request. Since it has beenmaintaining a session with the customer's browser 44, it knows who thecustomer is from the customer log on. In the embodiment in which asecured Web site is used, the customer's user profile contains acustomer identifier. This customer identifier designates the corporatebusiness client that the customer represents.

An illustrative example of a client is an employee of a corporatebusiness client who submits trouble tickets which are managed byCompany's trouble ticket database. In the call center, agents aretrained to service certain corporate customers. Skills designators areassigned to each agent to designate those corporate customers for whomthe agents are trained. There may also be skill levels (such as high,medium, low) to designate the level of training an agent has receivedfor a certain customer. Skills tables are stored in the Database Serverthat map skills designators and levels to agents.

Thus, when a call-back request is received from a customer 42, it mustbe sent to an agent who is trained to service the corporate businessclient represented by the customer. When the Intranet Server 66 receivesthe call-back request, it references the customer identifier from thecustomer's user profile. This customer identifier is added to thecall-back request, as it will be used as a skills designator.

In other embodiments, other data may be used as skills designators. TheInternet Protocol (IP) address of the customer browser 44 is alsocollected and added to the call-back request as a parameter.

The Intranet Server 66 passes the call-back request to the ContactServer 28. The call-back request generally include the informationentered by the customer, along with the customer identifier, IP address,and the Universal Resource Locator (URL, the Web site address) of theWeb page from which the call-back request was submitted. The ContactServer 28 queries a skills table on the Database Server 34 with thecustomer identifier (which is used in this example as a skillsdesignator) to identify those agents qualified to handle the call-backrequest. In one embodiment, a software product by Genesys® is used forthe skills tables, but other software can also be used.

The Contact Server 28 then queries the state tables on the DatabaseServer 34 to identify an available agent with the highest skill levelneeded to handle the call-back request. If a qualified agent isavailable, the Contact Server 28 sends the call-back request to thatagent. Otherwise, the call-back request is placed in a queue on theDatabase Server 34. The Contact Server 28 constantly monitors this queueand the state tables. If a qualified agent is available to handle acall-back request in queue, the Contact Server 28 sends the call-backrequest to that agent.

In alternate embodiments, a rules-based engine can be incorporated intothe Contact Server 28 to process rules in determining how to manage thecall-back queue and process call-back requests, as described inAlternate Embodiments and Features.

At the same time the Contact Server 28 sends a call-back request to anagent, the Contact Server 28 also sends a “not ready” message for thatagent to the CTI Server 18. This will prohibit the ACD 12 from routingany inbound calls to the select agent, so that the select agent will beavailable to place an outbound call to the customer 42. Included in thecall-back request that is sent to an agent workstation 14 are theinformation entered by the customer, the customer's IP address and theURL of the Web page from which the call-back request was submitted.

When the agent workstation 14 receives the call-back request, twoprocesses occur. First, a window is displayed with the call-backinformation which generally includes a customer name and a telephonenumber. Second, a CGI script is downloaded from the Web Server on theIntranet Server 66 to the agent workstation 14, and executed onthat-agent workstation 14. The call-back request passes as parameters tothe CGI script: the customer's IP address, the URL of the Web page fromwhich the call back request was submitted, and perhaps other informationas needed by a particular service application (trouble ticket #, etc.).The CGI script launches the agent's Web browser and dynamically buildsthe Web page with the Java applet from the Web Server 30. This presentsthe agent with the same Web page from where the customer's call-backrequest was issued. The customer's IP address (and perhaps otherservice-related data) are passed as parameters to the Java applet, whichis the same applet that is running on the customer's browser 44.Execution of this Java applet on the agent's browser establishes aTCP/IP communications session between the agent's browser running on theagent workstation 14 and the customer's browser 44. This communicationssession uses both push and pull technology for passing data between theagent 14 and the customer 42. The agent can perform actions on theirbrowser, such as drilling down in a menu hierarchy or typing text, andpush these updates to the customer's browser 44; or the customer 44 canpull these updates from the Web Server when they select an updateoption.

At the same time this agent to client communications session over theinternet 32 is established, the agent places an outbound call to thecustomer's call-back number. This can be accomplished in any of fourdifferent ways:

1. At the same time the Contact Server 28 sends the call-back request tothe agent, it sends a message to the CTI Server 18 to have the ACD 12place an outbound call to the customer's call-back number. The ACD 12places this call from the agent's workstation 14 (specifically, theagent's telephony station).

2. As an optional feature, the Contact Server 28 can set a timer when itsends the call-back request to the agent workstation 14. This timer(i.e., 30 seconds) allows the agent to review the call-back request andWeb page to become familiar with the customer's situation. At theexpiration of the timer, the Contact Server 28 sends a message to theCTI Server 18 to have the ACD 12 place an outbound call to thecustomer's call-back number. As another feature of the agentsworkstation 14, the agent can postpone the outbound call at theexpiration of the Contact Server's 28 timer or another configurableperiod of time; or the agent can simply pause the timer and have thecall placed when the agent is ready.

3. The dialog box presented to the customer 42 when placing a call-backrequest can prompt the customer 42 for a call-back time. If the customer42 does not enter a time, they are requesting a call-back as soon aspossible. Otherwise, they enter a time, which is passed in the call-backrequest to the Contact Server 28. The Contact Server 28 places thecall-back request in queue, and then processes it at the requested time.

4. The agent can manually trigger the outbound call from theirworkstation 14. Most agent workstations 14 are equipped with telephonecontrol software, which is used to place outbound calls by sending acommand to the CTI Server 18. In the preferred embodiment of the presentinvention, the agent can place an outbound call by sending a command tothe Contact Server 28, using a Contact Server API built into the agentworkstation 14. The Contact Server 28 in turn places the appropriatecommand with the CTI Server 18. This eliminates the need for an agentworkstation 14 interface with the CTI Server 18. This also simplifiesthe programming of agent workstation 14 applications, since only oneinterface (with the Contact Server 28) is needed, regardless of the typeand number of communications networks used, and regardless of the typeof CTI Server 18 used. This also simplifies the agent responsibilities.

The outbound call is placed to the customer's call-back number from theACD 12. When the customer 42 answers, the ACD 12 conferences in theagent. The agent and customer 42 can now proceed with a telephoneconversation, which represents the fulfillment of the customer'scall-back request. At the same time, the agent and customer 42 canengage in a TCP/IP communications session. During this session, theagent workstation 14 communicates directly with the Intranet Server 66;the Contact Server 28 does not play an active role, but monitors forwhen the session ends.

Establishment and maintenance of the TCP/IP session between the agentand customer is a novel feature. The Java applets that run on theagent's browser and the customer's browser 44 pass the events performedby the agent and customer to each other. This is very useful inconjunction with a telephone conversation. As the agent assists thecustomer 42 via verbal communication, the agent can display examples orpoint to items on the Web page. As the agent types in text or performsother visible actions on their browser, the agent hits an update optionon their browser. The update action causes the Java applet that isrunning to send the updates (agent's actions) to the Web Server 30.These updates can either be pushed to the customer browser 44, or thecustomer can pull them from the Web Server 30. Updates are sent in aproprietary application protocol that uses TCP/IP messaging. The Javaapplet running on the customer browser reads these updates and performsthem on the customer browser 44.

This technique also enables an on-line chat session to be conducted,which can replace or augment the telephone call.

More details on the call-back process are included in reference to FIG.7.

FIG. 3 is a context diagram illustrating the logical processes andinterfaces of the Contact Server 28.

The Contact Server 28 registers for events from the CTI Server 18 ofFIGS. 1 and 2; in this example, the T-Server 48 from Genesys. TheContact Server 28 has a T-Server Event Processor 50 that first performsthis registration, then receives and processes registered events fromthe T-Server 48. The T-Server Event Processor 50 uses T-Server 48 eventsto update state tables on the Database Server 34.

The Contact Server's 28 main process, an Event Processor and Router 52,is responsible for sending messages to the T-Server 48 for placingoutbound calls and reserving agents.

The Database Server 34 contains the call-back queues, state tables, andskills tables. The Event Processor and Router 52 is responsible forquerying the skills and state tables generally located in the DatabaseServer 34 to find qualified and available agents for call-back requests,and for querying the call-back queues to retrieve call-back requests forprocessing.

The Contact Server 28 has TCP/IP socket threads 54 that listen forevents from the Java Server 58 on the Web Server 30. The Contact Server28 specifically listens for call-back requests. The Intranet Server 66shown in FIG. 1 is a computer upon which a Web Server 30 process runs.Within the Web Server 30, a Java Server 58 runs. The Java Server 58serves the Java applets to the agent browser; an identical Java Serveron the Firewall Server 40 serves Java applets 58 to the customerbrowser.

The Contact Server 28 also has threads 54 that listen for events fromthe agent workstations 14 (“Agent Client”) and that receive data fromthe agent workstations 14, via a Contact Server API on each agentworkstation 14. For example, an agent may log off to take a break, inwhich case the Contact Server 28 will receive this event and update itsstate tables generally located in database server 34 to indicate thatagent is no longer available. The agents can set themselves as “ready”or “not ready”, or “available” or “not available” by sending these stateupdates to the Contact Server 28. This eliminates the need for an agentworkstation to make duplicate updates to each system they interfacewith, such as the CTI Server 18. The Contact Server 28 makes theseupdates in the state tables and tracks agent status. The Contact Server28 is used in this manner, independent of whatever communicationsnetworks are being used by the call center.

A Monitor 60 can be linked to the Contact Server 28 for the purpose ofdisplaying call-back messages, agent states, and owner informationprocessed by the Contact Server 28.

FIG. 4 illustrates the interfaces used for TCP/IP communications betweenthe agent and the customer. The Agent browser 64 communicates directlywith the Intranet Server 66, with the Contact Server 28 in FIGS. 1, 2,and 3, only monitoring for the termination of the session, so that itcan update its state tables.

The Intranet Server 66 is used for a Web Server 30 to support the Websites and TCP/IP communications for the services provided. Within thisWeb Server 30 are the Java applets that are downloaded to the agentbrowser. The Intranet Server 66 sits behind a router-based firewall 68for security. However, the Java applets cannot maintain communicationsthrough this firewall. Therefore, a Firewall Server 40 contains anidentical Web Server 70 with Java applets. It is from this Web Server 70on the Firewall Server 40 that the Java applets are downloaded to thecustomer browser 62. Once the Java applets are downloaded and running onboth the agent's 64 and customer's browsers 62, HTML files can be passedbetween the agent browser 64 and the customer browser 62.

FIG. 5 is an event state diagram showing the illustrative example ofstates and state transitions maintained in the state tables 72 generallylocated in the Database Server 34 of FIG. 3. Normally, states representthose for agents. State transitions are performed by the Contact Server28 and are triggered generally by events received from the CTI Server 18and Agent Workstations 14. State transitions can also be triggered bythe Contact Server 28, such as when it sends a call-back request to anagent.

Ovals represent actions (agent request, T-Server request, Contact Serverrequest). Rectangles represent states.

When an agent is in a “login” state 74, they are not yet recorded in thesystem (“agent not-in system”)76.

When an agent first logs in, they are placed in a “not-available” state78. In reference to the key, this corresponds to “agent state can't takenew call” 80. An agent must manually indicate (via an action taken attheir workstation—“Agent Request” 82) that they are ready. This triggersa transition to an “available” state 84. In reference to the key, inthis state, the “agent state can take call” 86.

The agent workstation has a toggle that can be set to call-backs “on” or“off” 88. If set to “off” (“Callbacks On”=no), the agent is placed in a“waiting” state 90. In reference to the key, in a “waiting” state 90, an“Agent State Can take Call” 86. If set to “on” (“Callbacks On”=yes), atest is performed to determine if any call-back requests are waiting inqueue. If not, the agent is placed in a “waiting” state 90. If call-backrequests are waiting, the agent is placed in an “on call” state 92. Inreference to the key, in an “on call” state, an “Agent State Can't takenew Call” 80.

If an agent is in a “waiting” state 90 and a call-back request arrivesand the agent's call-back toggle is set to “on” 88, the agent is placedin an “on call” state 92. In reference to the key, “Callback Arrives” isa “Contact Server Process” 94. Likewise, if an agent is in a “waiting”,state 90 and an event is established (“T-Server Event” 96) to indicatethe agent has received a call, the agent is placed in an “on call” state92.

In an “on call” state 92, an agent can hang up 96(“Agent Request” 82),which places the agent in a “wrap up” state 98, or the Contact Server 28receives a release or transfer event 100(“T-Server Event” 96), whichalso places the agent in a “wrap up” state 98. In a “wrap up” state 98,three “Agent Requests” 82 can be made. A logout 102 places the agent ina “logout” state 104. A “ready” 106 request places the agent in an“available” state 84. A “not ready” 108 request places the agent in a“not available” state 78. An agent can also make a “not ready” 108request from a “waiting” state 90.

FIG. 6 is a representative illustration of a sample HTML web page 208.Typically, a web browser such as Microsoft Explorer® or NetscapeNavigator® or Communicator® displays a HTML web page such as the oneshown in FIG. 6 by downloading a HTML file from a Web Server specifiedin URL. Additional pages may be displayed on top of the HTML web page208 by Java applets that are also downloaded from the Web Server andrunning on a client browser. Shown in FIG. 6 are two separate framesoverlaid on the html web page 208: a “Trouble ticket” frame 210; and a“Contact Me” frame 158, which enables a call back request. Both of theseframes are controlled by the Java applets downloaded from the WebServer.

“Trouble ticket” frame 210 is an example of what a customer may beviewing on their web page before a call back request is made. This frame210 also illustrates an example of how a customer may request to besynchronized with an agent by pushing on the “Sync With Agent” button212. Sync, Push, and Pull mechanism is explained in detail in referenceto the FIGS. 9( a), (b), and (c).

“Contact Me” frame 158 is controlled by a Java applet running on theClient browser. This Java applet handles call back screen interface withthe user and at the same time handles communications with the CallBackServer in the Web Server. The following paragraphs describe a detailedexample of how a CallBack Java Applet may function in interfacing withthe user and a Server.

Description of CallBack Java Applet Running on Client Browser:

-   -   1. Initialize all data parameters.    -   2. Get I/O connection from host (i.e., CallBack Server).    -   3. Get host parameters and port address for communication over        socket.    -   4. Construct “Contact Me” screen and display it on Client's        current screen.    -   5. Handle input events from the Client's screen; i.e., mouse        input, keyboard input.        -   5.1 If input event is a mouse click on a Name field, display            message, “enter your name.”        -   5.2 If input event is a mouse click on a Phone Number field,            display message, “enter your phone number”.        -   5.3 If input event is on a Contact-Method field and the            Contact Method chosen is “Telephone”, enable phone number            and extension fields on the Client's screen; for all other            Contact Method chosen, disable phone number and extension            fields.        -   5.4 If CallMeButton click event, then check if all the input            parameters are entered.        -   5.4.1 If input parameters are missing, display message. “Not            enough information to complete call”; and return to step 5,            and handle more input.        -   5.4.1 If all the input parameters are entered, proceed to            step 6.    -   6. Parse input parameters.    -   7. If Contact Method chosen is “Agent/Customer On Line Chat”,        include CGI script name in the URL path to be sent over a socket        to CallBack Server; package input parameters into a buffer and        write buffer over the socket connection to CallBack Server.    -   8. If Contact Method chosen is “E-Mail”, include Customer's        e-mail address in a send buffer; write buffer over the socket.    -   9. If Contact Method chosen is “Telephone”, include Customer's        telephone number in a send buffer; write over the socket.        -   9.1 Wait for CallBack Server to send confirmation that call            has been placed.        -   9.1.1 If no confirmation arrives from the CallBack Server in            a definite time-out period, display message, “There has been            an error in receiving confirmation that your call has been            placed”, on Client's screen.    -   10. Listen over the socket for messages from the CallBack        Server. (A new thread)        -   10.1 If message received from the CallBack Server is            “Contact Server Down”, display message on the Client's            screen, “Call me back function is not available.”        -   10.2 If message received from the CallBack Server is            “Contact Server Up”, display message, “To speak with an            agent, please click on the Contact Me button. We will be            happy to call you regarding your service inquiries.”        -   10.3 If message received is “Event”, parse the message            received and compare even types.        -   10.3.1 If event type is “Insert Call Back”, display message,            “Thank you for using MCI Web Callback Service. Your call has            been placed and an MCI Technical Specialist is contacting            you now.”        -   10.3.2 If event type is “Delete Call Back”, display message,            “Your call has been canceled.”        -   10.4 Proceed to step 10.

Description of CallBack Server Running in Web Server:

One of the functions of this CallBack Server is to interact with theabove CallBack applet.

-   -   1. Open connection with Contact Server.    -   2. If no connection, set a parameter “Contact Server Down”,        package message into a buffer and send to CallBack applet.    -   3. If connection exists, set a parameter “Contact Server Up”,        package message into a buffer and send to CallBack applet.    -   4. Open connection with CallBack applet. (A new thread)    -   5. Accept data from CallBack applet.    -   6. Parse message from CallBack applet.        -   6.1.    -   If Callback service was requested, call JContactClient class        with event type set to “InsertCallBack”.        -   6.2. If cancellation of callback service was requested, call            JContactClient class with event type set to            “DeleteCallBack”.

FIGS. 7 a, 7 b and 7 c together comprise a flowchart illustrating theprocess of a call-back service using the Contact Server and the forgoingclasses and functions. This shows a specific embodiment of the presentinvention, in which the call-back service is implemented for a securedWeb site that requires user authentication. At the company, the ContactServer will be used with a Web site that allows the company's customersto access the company's trouble ticket system and view the status oftheir tickets. Therefore, each customer has a user profile setup in aprofile database on the Database Server. It is from this database thatskills designators are obtained.

A similar type of call-back service can be implemented with the ContactServer for other applications, not all of which require user login.Additionally, the Contact Server can be used to accept call-backrequests from sources other than the Internet.

In step 110, a customer logs into a Web site. The Web Serverauthenticates the customer's user i.d. and password against thecustomer's user profile, which is stored in a database on the DatabaseServer. If the customer is authenticated, the Web Server sends to thecustomer browser the HTML file that contains the Web site's home page.Embedded in this file are the Java applets that will be used toestablish communications between the agent workstation and the customerPC. The Java applets perform other functions, such as present the dialogbox for completing a call-back request in step 110.

The Web Server maintains a session with the customer browser over theInternet using cookies or other session maintenance technology. Thisway, when the customer submits a call-back request, the Web Server canidentify that customer for the purpose of matching the call-back requestto a qualified agent.

The customer can now browse the Web site. In the embodiment with thetrouble ticket system, the customer can view the status of their troubletickets. During this course, the customer may have a question or otherreason to talk to a service rep (call center agent).

In step 112, the customer selects the call-back feature, which istypically an HTML button on a Web page. This causes a dialog box to bepresented to the customer to prompt them for their name and call-backtelephone number. The call-back telephone number can also include anextension, so that it the customer is calling from a PBX and an operator(live or automated) answers the phone on the call-back, the call centeragent will know the extension needed to reach the customer.

Additional information can be solicited here as well, such as a customeridentifier that can be used as a skills designator to match thecall-back request to a qualified agent. A call-back time can besolicited, to state when the customer would like to be called back.Call-back time can be entered either as a specific clock time (i.e, 3:00pm est), or as a duration (i.e., 20 minutes from now). Without acall-back time entered, it is assumed the customer is requesting acall-back as soon as possible.

In step 114, when the customer completes the call-back request dialogbox and hits enter, the customer browser sends the call-back request tothe call center Web Server, via the Internet.

In step 116, the Web Server receives the call-back request and forwardsit to the Contact Server. In addition to the information provided by thecustomer in step 110, the Web Server includes in the call-back requestmessage that it forwards to the Contact Server: the IP address of thecustomer, URL of Web page from which the call-back request was selected,and the customer identifier of the customer. The customer identifier isobtained from the customer's user profile when the customer logs on instep 110. In this embodiment, it is used as a skills designator. Thecustomer's IP address and the URL will be provided to the agentworkstation.

In step 118, the Contact Server queries the skills database with theskills designator (i.e., the customer identifier) to find a qualifiedagent; that is, an agent listed with that particular skills designator.The Contact Server actually identifies all agents with that skill, sothat if one agent is not currently available, another agent can be used.

In step 120, the Contact Server queries the state table to find anavailable agent with the highest skill level of the needed skill.

In step 122, if a qualified agent is available, then the Contact Serverproceeds to step 130.

If an agent is not available, then in step 124, the Contact Serverplaces the call-back request in a call-back queue on the DatabaseServer.

Step 126 represents a continuous process performed by the ContactServer. It monitors the call-back request queue and state tables, anddetermines if a qualified agent is available to take a call-back requestin queue. In doing this, and as an additional feature, the ContactServer may apply business rules. For example, if a call queue on the ACD(which may be represented in the state table) is above a threshold, theContact Server does not process call-back requests in queue, and willnot until the call queue falls below a threshold. Or if the call-backrequest queue is above a certain threshold, the Contact Server mayreject the next call-back request, sending the customer a message sayingthat the customer's call-back request cannot be processed at this time.

In step 128 the Contact Server determines if a call-back request inqueue can be processed.

In step 130, the Contact Server sends a “not ready” message to the CTIServer for the agent selected in step 120. This will cause the ACD tonot send any inbound calls to that agent, so that the agent will beavailable to place the outbound call to the customer.

In step 132, the Contact Server sends the call-back request to theselect agent workstation. This request includes all information enteredby the customer, as well as the customer's IP address and the URL of theWeb page from which the call-back request was placed. The agentworkstation, when it receives the call-back request, screen-pops thecall-back request in a window displaying the customer's name, call-backnumber, and perhaps other information entered by the customer.

In step 134, a CGI (Common Gateway Interface) script is downloaded fromthe Web Server, and is executed on the agent workstation. It launchesthe agent's browser. The URL is passed as a parameter to the CGI script.The CGI script can then build the same Web page that the customer was atwhen they placed the call-back request. In reference to FIG. 4, theagent browser retrieves Web pages from a Web Server on the intranetServer 66, while the customer retrieves identical web pages from anidentical Web Server on the Firewall Server.

In step 136, a Java applet is downloaded to the agent browser from theWeb Server on the Intranet Server. The customer's IP address is passedas a parameter by the CGI script. The agent browser displays the sameWeb pace as the customer browser.

In step 138, the Java applet that was downloaded in step 136 establishesand maintains TCP/IP communications between the agent browser and thecustomer browser, using the customer's IP address that was included inthe call-back request sent to the agent workstation.

In step 140, the Contact Server sends a message to the CTI Server tocause the ACD to place an outbound call to the customer's call-backnumber. As noted in reference to FIGS. 1 and 2, this can occur in any ofa number of ways and at any of a number of points in the process. In thepreferred embodiment, the Contact Server sends this message at the sametime it sends the call-back request to the agent workstation, in step132. Alternately, the Contact Server can set a timer in step 132. Whenthe timer expires, step 140 is triggered.

In step 142 and in response to the message sent by the Contact Server instep 140, the ACD places an outbound call to the customer's call-backnumber. The call is placed from the agent's telephone station, so thatthe agent's telephone line to the ACD is seized during this process. Thecustomer may or may not answer, as determined in step 144.

If the customer answers, then in step 148, both telephony and TCP/IPcommunications sessions proceed between the agent and the customer.

In step 150, the call completes and the customer and agent each hangup.

Referring back to step 144, if the customer does not answer, then instep 146, a TCP/IP communications session can still proceed between thecustomer and agent. In fact, an on-line chat session can replace atelephone call.

In step-152, the agent terminates the TCP/IP session.

In step 154, the Contact Server updates the state tables to show theagent is now available.

The following Agent Client API table lists the events, possible sourcesof each event, and actions taken by the Contact Server in updating theabove state table and the state diagram of FIG. 5 in response to eachevent.

CContactEvent Class:

The CContactEvent class is a wrapper class that wraps socket and TServerdata. The class includes of 25 protected member variables:

Variable Name Type Description m_AgentID CString Unique identifier for aparticular agent. m_Ani CString Telephone number for the requestedcallback m_CollectedDigits CString Caller entered digits on a VRU.m_DefaultData CString Data attached to every call. m_Dnis CString Dialnumber identification service. m_ErrorMessage CString Description oferror that has occurred. m_OtherDN CString Destination number (DN) acall was transferred from m_OtherQueue CString Queue a call wastransferred from m_TeleEvent CString Description of request/eventcorrelating to TMessageType enum located in Ttypes.h. m_ThisDN CStringCurrent DN. m_ThisQueue CString Current queue. m_UserData CString Dataspecific to this event m_IP CString URL related to soecific callback.m_CallID long Switch's unique identifier for a call. m_CallType longRefers to Web Phone, Telephone, See You See Me m_ConnID long T-Server'sunique identifier for a call. m_ErrorCode long Numeric code for errorthat has occurred. m_FileHandle long Voice mailbox file. m_OtherTrunklong Trunk a call was transferred from. m_UserRefNumber long Number ofrequests related to this event. m_ThisTrunk long Current trunk.m_TimeInQueue long Amount of time a call/callback has waited in queuem_Event short Numeric code correlating to TMessageType enum fromTtypes.h. m_LastCollectedDigit short Last caller digit entered on VRU.m_LoginType short Type of loqin used: DN, PCLogin, ACDLogin, OtherCContactEvent Functions:

Constructors: The class includes two constructors. The first is astandard default constructor taking no parameters and performing noadditional tasks. The second constructor takes one CString parameterwhich is pipe (“|”) deliminated.

-   This constructor sets the member variables by calling the    GetKeyValue( . . . ) function to parse out the data from the CString    parameter passed to it.-   void SetVariableName( . . . ): The CContactEvent class includes 25    functions to set, or assign, the value of each member variable, one    function per variable. Each function takes one parameter of the same    type as the member variable that it corresponds to, sets the    variable, and has a returns void.-   type GetVariableName( ): The CContactEvent class also includes 25    functions to get, or return, the value of each member variable, one    functions corresponding to each variable. These functions do not    take any parameters, and returns the value stored within the    corresponding member variable.    CString GetSocketString( ):-   This function returns a CString of “|” deliminated key-value pairs    to send on a socket to a listener/server. The key-value pairs the    function deliminates are the member variables of the CContactEvent    class. The function will test each member variable to determine it    is populated. If populated, it will add the variable key and its    data to the CString it returns.    void ClearEvent( ):-   This function will clear out any data that is stored in any of the    object's member variables, with the exception of m_ThisDN. m_ThisDN    is kept because the destination number will remain the same while    the agent is connected to the server. The return value is void.    short DeleteUserData(long lParam, LPCTSTR dn, LPCTSTR szInKey):-   This function takes three parameters, however, it does not use the    first two (lParam & dn). The function is designed to delete a    portion of the m_UserData variable, which must be a “,” deliminated    string. The szInKey parameter is the key of the data the function    will delete, and the function will delete the data in the string    that resides between the two commas following the key.    short DeleteAllUserData(long lparam, LPCTSTR dn):-   The function does not use the two parameters passed. The function    will set the m_UserData member variable to an empty string (“”)    CContactClient Class:-   The CContactClient class is an API designed to facilitate the    communications between the Agent application and the CServer via    TCP/IP sockets by establishing/terminating the server connection and    sending/receiving data. Additionally, the CContactClient class    functions as a wrapper for the CContactEvent class.    Variables:-   Variable names followed by (.cpp) are declared within the .cpp file    rather than the .h file. This is so the ReceiveThread function, a    statically declared function, can use these variables.

Variable Name Type Description m_ServerName CString Stores the IPaddress of the server connected to. pEventSocket CContactSocket Pointerto a CContactSocket object. ConnectionStatus SocketStatus Enum typedefined in the CContactSocket class. Refers to the status or the socketconnection to the server. CurrentEvent CContactEvent InboundCContactEvent object from the socket. TMessageString CString arrayString representation [86] of the TMessageType enum from Ttypes.h.ErrMsg (3) CString array Error string message associated with the#define constants listed in the previous section. pListenerSocketCContactSocket Pointer to CContactSocket (.cpp) object the receivethread uses. EVENT_OBJECT struct Structure for a single (.cpp) linkedlist containing a CContactEvent object and a pointer to the next link.pEventHead (.cpp) EVENT_OBJECT Pointer to the head of the linked list.OutboundEvent CContactEvent CContactEvent object to be (cpp) sent toCServer. m_hWindow (.cpp) HWND m_lWindow (.cpp) long m_Msg (.cpp) UINTm_hListender HANDLE Handle for receive thread.Functions:

-   Constructor: The constructor initializes the pointers pEventHead,    pEventSocket, and pListenerSocket to null; initializes the string    messages for the ErrMsg array; and initializes the string    descriptions for the TMessagestring array.-   Destructor: Calls CContactEvent's member function ClearEvent( ) to    clear data stored in CurrentEvent and OutboundEvent. Deletes all    elements that may exist in the EVENT_OBJECT linked list, including    pEventHead.-   Closes the receive thread and sets pListenerSocket to null.    Disconnects from CServer and sets pEventSocket to null.    short Open(LPCTSTR szServerName)    short Open(LPCTSTR szServerName, ClientType client):-   This overloaded function takes one or two parameters. szServerName    refers to the IP address of the server to connect to and client    refers to the type of client logging in (i.e., monitor client, agent    client, or web client).-   The function checks pEventSocket for a null value. If null, it    allocates and CContactSocket object with the new keyword. Next, the    function checks ConnectionStatus for a connected state. If    connected, it sets an error message advising a server connection    already exists and returns a false, or 0, value. If no connection    exists, the function sets the client type for the CContactSocket    with client, or a default of AGENT_CLIENT if the function does not    receive a client parameter; sets CContactClient's m_ServerName with    szServerName; and calls CContactSocket's connect function to make a    connection to the server.-   If the connection fails, the function sets an error message with the    error received from the CContactSocket object, deletes pEventSocket,    and the function will exit With a false value.-   If a successful connection occurs, a second thread is started for    receiving events from CServer.    short CloseServer( ):-   Calls CContactEvent's member function ClearEvent( ) to clear data    stored in CurrentEvent and OutboundEvent. Deletes all elements that    may exist in the EVENT_OBJECT linked list, including pEventHead.    Closes the receive thread and sets pListenerSocket to null.    Disconnects from CServer and sets pEventSocket to null.    short isEventReady( )    short NextEvent( ):-   These two functions have the same functionality.-   These functions will remove the first element in the EVENT_OBJECT    linked list and shift the second link to the head. When called, if    pEventHead is null, the function(s) clear any data that CurrentEvent    has stored in its member variables and sets the return value to    false, or 0.-   If the first element in the list is the only element, the function    removes the element and sets pEventHead to null. Otherwise, the    function removes the first element and the second link becomes the    first.    CString GetSocketString( ):-   This function calls CContactEvent's GetSocketString function to    format CurrentEvent's member variables into a single, pipe (“|”)    deliminated string. The function returns the formatted string.    void CreateEvent(CContactEvent NewEvent):-   This function will add a received event to the end of the    EVENT_OBJECT linked list. If an empty list exists, it adds NewEvent    as the first link.-   Otherwise, the function will add NewEvent to the end of the list.    BOOL StartThread(LPCTSTR ServerName, ClientType Client):-   This function calls CreateThread (MFC) to start the receive thread.    static DWORD WINAPI ReceiveThread(LPVOID socket):-   This is the second thread designed to receive incoming events from    CServer. The thread loop will block on the socket until an event is    received. When received, the function will pass the event to    CreateEvent(CContactSocket NewEvent) for addition to the linked    list. If the received event is EventRegisterMachine, the function    sets OutboundEvent's m_ThisDN variable with the m_ThisDN variable of    the CContactEvent object received. Additionally, the function will    post a message to the window if one is received.    Wrapper functions for CContactEvent:    -   void SetVariableName(type): The following functions act as a        wrapper for the CContactEvent class. Each function is operating        on the OutboundEvent object to set its member variables prior to        sending the object to CServer. They accomplished by calling the        object's member function(s) that correspond to setting the        desired member variable. Each function takes a single parameter        of the same type as the CContactEvent member variable to set and        has a return value of void.    -   type GetVariableName( ): Again, the following functions act as a        wrapper for the CContactEvent class. Each function is operating        on the CurrentEvent object to get the data stored in its member        variables. This is accomplished by calling the object's member        functions that correspond to retrieving the desired member        variable. Each function takes no parameters and returns a value        of the same type as the CContactEvent member variable to        retrieve.        short CallbackOn(LPCTSTR dn, short logType):-   this function requests CServer set the agent's ability to handle    callbacks on. It sets the OutboundEvent's m_Event to    EventCallbackOn, and sets m_ThisDN and m_LoginType with the    parameters passed.    The function will check pEventSocket for a null value. If null, the    function sets an error message advising no server connection exists    and will return a false, or 0, value. Next, the function will test    OutboundEvent's m_ThisDN for an empty string. If empty, it sets an    error message advising no DN registered and will return a false    value. Lastly, the function will check the ConnectionStatus variable    for a connected state. If not connected, it sets an error message    advising no server connection exists and will return a false value.    If these three tests pass, the function will send the outboundEvent    to the CServer over the socket and return a true, or 1, value. Prior    to exiting, the function calls CContactEvent's ClearEvent function    to clear data stored in the OutboundEvent's member variables.    short AgentLogout(long lparam, LPCTSTR dn):-   This function requests CServer log the agent out. It sets    OutboundEvent's m_Event with RequestAgentLogout and m_ThisDN with    dn.    The function will check pEventSocket for a null value. If null, the    function sets an error message advising no server connection exists    and will return a false, or 0, value. Next, the function will test    OutboundEvent's m_ThisDN for an empty string. If empty, it sets an    error message advising no DN registered and will return a false    value. Lastly, the function will check the ConnectionStatus variable    for a connected state. If not connected, it sets an error message    advising no server connection exists and will return a false value.    If these three tests pass, the function will send the OutboundEvent    to the CServer over the socket and return a true, or 1, value. Prior    to exiting, the function calls CContactEvent's ClearEvent function    to clear data stored in the OutboundEvent's member variables.    short MakeCall(long lparam, LPCTSTR dn, LPCTSTR szPhoneNumber):-   This function requests CServer place a call. It sets OutboundEvent's    m_Event with RequestMakeCall, m_Ani with szPhoneNumber, and m_ThisDN    with dn. The function does not use lParam.    The function will check pEventSocket for a null value. If null, the    function sets an error message advising no server connection exists    and will return a false, or 0, value. Next, the function will test    OutboundEvent's m_ThisDN for an empty string. If empty, it sets an    error message advising no DN registered and will return a false    value. Lastly, the function will check the ConnectionStatus variable    for a connected state. If not connected, it sets an error message    advising no server connection exists and will return a false value.    If these three tests pass, the function will send the OutboundEvent    to the CServer over the socket and return a true, or 1, value. Prior    to exiting, the function calls CContactEvent's ClearEvent function    to clear data stored in the OutboundEvent's member variables.    short CallAnswer(long lparam, LPCTSTR dn):-   This function requests CServer answer a call. It sets    OutboundEvent's m_Event with RequestAnswerCall and m_ThisDN with dn.    The function does not use lParam.    The function will check pEventSocket for a null value. If null, the    function sets an error message advising no server connection exists    and will return a false, or 0, value. Next, the function will test    OutboundEvent's m_ThisDN for an empty string. If empty, it sets an    error message advising no DN registered and will return a false    value. Lastly, the function will check the ConnectionStatus variable    for a connected state. If not connected, it sets an error message    advising no server connection exists and will return a false value.    If these three tests pass, the function will send the OutboundEvent    to the CServer over the socket and return a true, or 1, value. Prior    to exiting, the function calls CContactEvent's ClearEvent function    to clear data stored in the OutboundEvent's member variables.    short AgentReady(long lparam, LPCTSTR dn):-   This function requests CServer set an agent's status to ready. The    function sets OutboundEvent's m_Event to RequestAgentReady and    m_ThisDN with dn. The function does not use lParam.    The function will check pEventSocket for a null value. If null, the    function sets an error message advising no server connection exists    and will return a false, or 0, value. Next, the function will test    OutboundEvent's m_ThisDN for an empty string. If empty, it sets an    error message advising no DN registered and will return a false    value. Lastly, the function will check the ConnectionStatus variable    for a connected state. If not connected, it sets an error message    advising no server connection exists and will return a false value.    If these three tests pass, the function will send the OutboundEvent    to the CServer over the socket and return a true, or 1, value. Prior    to exiting, the function calls CContactEvent's ClearEvent function    to clear data stored in the OutboundEvent's member variables.    short AgentNotReady(long lparam, LPCTSTR dn):-   This function requests CServer set an agent's status to not ready.    The function sets OutboundEvent's m_Event to RequestAgentNotReady    and m_ThisDN with dn. The function does not use lParam.    The function will check pEventSocket for a null value. If null, the    function sets an error message advising no server connection exists    and will return a false, or 0, value. Next, the function will test    OutboundEvent's m_ThisDN for an empty string. If empty, it sets an    error message advising no DN registered and will return a false    value. Lastly, the function will check the ConnectionStatus variable    for a connected state. If not connected, it sets an error message    advising no server connection exists and will return a false value.    If these three tests pass, the function will send the OutboundEvent    to the CServer over the socket and return a true, or 1, value. Prior    to exiting, the function calls CContactEvent's ClearEvent function    to clear data stored in the OutboundEvent's member variables.    short AgentBusy(long lparam, LPCTSTR dn):-   This function requests CServer set an agent's status to busy. The    function sets OutboundEvent's m_Event to RequestAgentBusy and    m_ThisDN with dn. The function does not use lParam.    The function will check pEventSocket for a null value. If null, the    function sets an error message advising no server connection exists    and will return a false, or 0, value. Next, the function will test    OutboundEvent's m_ThisDN for an empty string. If empty, it sets an    error message advising no DN registered and will return a false    value. Lastly, the function will check the ConnectionStatus variable    for a connected state. If not connected, it sets an error message    advising no server connection exists and will return a false value.    If these three tests pass, the function will send the OutboundEvent    to the CServer over the socket and return a true, or 1, value. Prior    to exiting, the function calls CContactEvent's ClearEvent function    to clear data stored in the OutboundEvent's member variables.    short AgentNotBusy(long lparam, LPCTSTR dn):-   This function requests CServer set an agent's status to not busy.    The function sets OutboundEvent's m_Event to RequestAgentNotBusy and    m_ThisDN with dn. The function does not use lparam.    The function will check pEventSocket for a null value. If null, the    function sets an error message advising no server connection exists    and will return a false, or 0, value. Next, the function will test    OutboundEvent's m_ThisDN for an empty string. If empty, it sets an    error message advising no DN registered and will return a false    value. Lastly, the function will check the ConnectionStatus variable    for a connected state. If not connected, it sets an error message    advising no server connection exists and will return a false value.    If these three tests pass, the function will send the OutboundEvent    to the CServer over the socket and return a true, or 1, value. Prior    to exiting, the function calls CContactEvent's ClearEvent function    to clear data stored in the OutboundEvent's member variables.    short DeleteCallback (CString ANI, CString IP):-   This function requests CServer delete a callback. It sets    OutboundEvent's m_Event to RequestDeleteCallback, m_Ani with ANI,    and m_IP with IP.    The function will check pEventSocket for a null value. If null, the    function sets an error message advising no server connection exists    and will return a false, or 0, value. Next, the function will test    OutboundEvent's m_ThisDN for an empty string. If empty, it sets an    error message advising no DN registered and will return a false    value. Lastly, the function will check the ConnectionStatus variable    for a connected state. If not connected, it sets an error message    advising no server connection exists and will return a false value.    If these three tests pass, the function will send the OutboundEvent    to the CServer over the socket and return a true, or 1, value. Prior    to exiting, the function calls CContactEvent's ClearEvent function    to clear data stored in the OutboundEvent's member variables.    short UpdateCallback(cstring appl_data, CString origination, CString    method,    -   CString IP, CString ANI, CString    -   NaspID, CString ContactTime,    -   int ContactResult):        This function requests CServer update an existing callback. It        sets OutboundEvent's m_Event to RequestUpdateCallback, m_IP with        IP, and m_Ani with ANI. The remaining parameters are formatted        into a “Λ” deliminated string and set to OutboundEvent's        m_UserData variable.        The function will check pEventSocket for a null value. If null,        the function sets an error message advising no server connection        exists and will return a false, or 0, value. Next, the function        will test OutboundEvent's m_ThisDN for an empty string. If        empty, it sets an error message advising no DN registered and        will return a false value. Lastly, the function will check the        ConnectionStatus variable for a connected state. If not        connected, it sets an error message advising no server        connection exists and will return a false value. If these three        tests pass, the function will send the OutboundEvent to the        CServer over the socket and return a true, or 1, value. Prior to        exiting, the function calls CContactEvent's ClearEvent function        to clear data stored in the OutboundEvent's member variables.

FIG. 8 is a diagrammatic illustration of one possible implementation ofthe push/pull synchronization of the agent and customer web browsers.When a customer logs into a Web site, the Web Server 30 sends to thecustomer browser 202 the HTML file that contains the Web site's homepage. Embedded in this file are the Java applets 58 that will be used toestablish communications between the agent workstation 14 in FIG. 1 andthe customer PC 42 in FIG. 1. During this communications session, agentand client may view each other's actions and Data States on his/her Webpages through the Sync, Push, Pull mechanism.

Also shown in FIG. 8 is an illustration of how additional stations maylisten in on conversation between a client and an agent over theinternet using the same Sync, Push, Pull mechanism. For example, amanager station 208 may want to monitor various informations andactivities that are being transferred between a client and an agent.This can be accomplished when a Manager's Java Applet 58 registers withthe Data Server 206 and requests to be in a “Sync” mode in the samemanner as the Sync, Push, Pull mechanism explained in detail below.

FIGS. 9( a)(b) and (c) illustrate one possible logical implementation ofthe push/pull synchronization of the agents web browser 204 of FIG. 8and customer web browser 204 of FIG. 8. In step 160 of FIG. 9, the AgentApplet 58 of FIG. 8 registers with Data Server 190 using the Customer'sIP address. This enables the Data Server 206 of FIG. 8 to link theparticular Customer with that Agent.

In step 162 of FIG. 9, the Data Server 206 illustrated in FIG. 8establishes a link between the Client Java Applet 58 and the Data Server206 utilizing a system implemented TCP/IP socket communicationsmechanism. Data Server 206 creates a socket, binds to the networkaddress and listens in for a connection from the Client Java Applet 58.The Client Java Applet 58 then creates a socket and connects to the DataServer 206.

As illustrated in FIG. 9( b), the Applet 58 illustrated in FIG. 8 thenperforms the following functions: at step 166, one thread listens inover the socket ready to receive data from the Data Server 206, whileanother thread 178 waits for Customer screen updates, ready to transferthe updated Data State over the socket to Data Server 206.

In step 164, of FIG. 9( a), the Data Server 206 illustrated in FIG. 8establishes a link between the Agent Java Applet 58 and the Data Server206, utilizing a system implemented TCP/IP socket communicationsmechanism. The Data Server 206 of FIG. 8 listens in on the socket itcreated for a connection from the Agent Java Applet 58. A connection isestablished when the Agent Java Applet 58 of FIG. 8 creates a socket(e.g., by a call to socket ( )) and connects (e.g., connect( ) call) tothe Data Server 206.

As illustrated in FIG. 9( c) the Applet 58 of FIG. 8 then performs thefollowing functions: (a) one thread listens in over the socket ready toreceive data from the Data Server 206 as illustrated in step 172; (b)while another thread, at step 174 waits for Agent screen updates, readyto transfer the updated Agent Data State over the socket to Data Server206.

In step 166, of FIG. 9( a), the Data Server 206 illustrated in FIG. 8monitors the Client 58 to Data Server 206 socket link, and the Agent 58to Data Server 206 socket: link, for incoming messages from the ClientJava Applet 58 and the Agent Java Applet 58.

As illustrated in step 168 of FIG. 9( a), when a message is receivedfrom the Client Java Applet 58 of FIG. 8, the Data Server 206 reads thesocket handle at step 180 and performs the appropriate function at step182, and relays at step 184, the message to the Agent Java Applet 58 bywriting on the socket link established between the Agent Java Applet 58and the Data Server 206 illustrated in FIG. 8.

A message from the Client Java Applet 58, for example, could be thatCustomer has changed screens. In a Sync mode, the Data Server 206 wouldread this data over the socket from the Client Java Applet 58, interpretthe data and perform additional bookkeeping functions if any, and writethis changed screen data over another socket to the Agent Java Applet58. The Agent Java Applet 58 reads this data and displays it on theAgent's Web page. As a result of this action Customer and Agent view thesame screen data on their Web pages.

At step 170 of FIG. 9( a), when a message is received from the AgentJava Applet 58, the Data Server 206 reads at step 186, and performs atstep 188, the appropriate function, and relays at step 190 the messageto the Client Java Applet 58 of FIG. 8 by writing on the socket linkestablished between the Client Java Applet 58 in FIG. 8 and the DataServer 206 of FIG. 8. A message from the Agent Java Applet 58, forexample, could be a request to send the agent's Data State to theCustomer (i.e., a Push example). The Data Server 206 reads andinterprets this message and writes the Data State on the socketconnected to the Client Java Applet 58 which has the same IP address asthe one with which the Agent Java Applet 58 has registered. The ClientJava Applet 58 then reads the data and displays it on the Customer's Webpage, resulting in the Push action.

The Sync, Push, Pull of the web pages include Java applet states,thereby making it compatible to work with ActiveX controls and otherapplications.

The above description is embodiment of the present invention; that is,accepting call-back requests over the Internet and fulfilling thoserequests with both a telephone call placed from a call center ACD and aTCP/IP communications session over the Internet. A novel feature of theContact Server is that it can be used with virtually any communicationstechnology. It essentially manages agent contacts with customers andplaces call-back requests. Several additional embodiments and featurescan be realized, some of which are noted below.

The Contact Server can be used in several different embodiments of callcenters, using different communications technologies such as PSTNtelephony, Internet data communications, or Internet telephony.

FIG. 10 is a diagrammatic illustration of the logical networkarchitecture of a company call center of FIG. 1 which utilizes alternateIP telephony protocols for communication between the agent and thecustomer. An Internet/Telephony Gateway (ITG) 192 is used to providetelephone call services over the Internet 32. A call center agent canplace a standard outbound call via the ACD 12 to the PSTN 20, but havethe call routed to the ITG 192, which terminates the call as avoice-over-IP 194 call over the Internet 32 to an IP address 196.Likewise, a call can be placed from an IP address 196, access the ITG192 via the Internet 32, and terminate to a call center agent via thePSTN 20.

Also shown is a direct link to the Internet 32 for agent workstations14, using an IP switch 198. Agent workstations 14 in this embodiment arenormally PCS equipped with Internet telephony capabilities, which arebecoming common. This also enables video telephony, so that a videoconference between the agent and customer can be setup using thecall-back services provided by the Contact Server 28.

Call-back requests can also be placed over the PSTN 20. When a customercalls in to the call center and the call is routed by the ACD 12 to aVRU 16. This is standard practice. The VRU 16 can then collect callerinformation regarding the type of services required. The VRU 16 thenqueries the Contact Server 28 to determine if an agent is available orif the queue is above a certain threshold. If so, the VRU 16 can promptthe caller to place a call-back request. A similar method is describedin another disclosure (COS-97-002); however, the present inventionallows the call-back request to be submitted to the Contact Server 28,which can place a call-back using any available communicationstechnology.

For examples, the Contact Server 28 can:

-   -   receive a callback request via the Internet 32, and place an        outbound call to the customer 42 over the PSTN 20;    -   receive a callback request via the Internet 32, and place an        outbound call to the customer 42 over the Internet 32;    -   receive a callback request via the PSTN 20/ACD 12/VRU 16, and        place an outbound call to the customer 42 over the PSTN 20;    -   receive a callback request via the PSTN 20/ACD 12/VRU 16, and        place an outbound call to the customer 42 over the Internet 32;    -   receive a callback request via the Internet 32 or PSTN 20/ACD        12/VRU 16, and place a video call to the customer 42 over the        Internet 32;    -   receive a callback request via the Internet 32, and establish a        TCP/IP session with the customer 42 over the Internet 32 and use        on-line chat facility.

The Contact Server 28 can even receive a manual feed of callbackrequests. For example, a marketing representative may feed a list ofnumbers for sales leads to the Contact Server 28, which submitscall-back requests to agents for these numbers.

Other features include:

If an available agent is not found within a certain time (90 seconds),the Contact Server 28 rejects the call-back request and sends a messageto the customer 42 saying that the call-back request cannot be processedat this time.

Agents may need to access various systems to service a customer 42. Forexample, agents may need to access a mainframe customer informationsystem. If this system is down, the agent cannot service a customer 42,and it would be a waste of resources to place a call to that customer42. Therefore, the Contact Server 28 can have an interface to a processthat monitors this system. If this system is down, the Contact Server 28rejects the call-back request and sends a message to the customer 42saying that the call-back request cannot be processed at this time. Thiscan also be used with call-back requests received by the VRU 16 for PSTN20 calls. The VRU 16 can determine what system is needed to service acustomer 42, then query with that system's process monitor, anddetermine if the system is available. If the system is not available,the VRU 16 prompts the customer 42 to submit a call-back request. Thecall-back request is sent to the Contact Server 28. When the ContactServer 28 detects that the system is again available, the Contact Server28 issues a command to the CTI Server 18 to have the VRU 16 place anoutbound call to the customer 42.

If a queue time is above a threshold when a PSTN 20 call arrives at theACD 12, the call is routed to a VRU 16. The caller is prompted to placea call-back request, which is then submitted to the Contact Server 28.Instead of a telephone number, the caller can enter an IP address, andhave a call-back placed via the Internet 32.

A rules-based engine can be included in the Contact Server 28 todetermine the action to take on a call-back request, based on criteriasuch as ACD 12 call queue, call-back request queue, etc. For example, ifa call-back request queue is above a threshold, the Contact Server 28can reject a call-back request and send a message to customer 42 statingthat their request can not be processed at this time.

The Contact Server 28 can monitor the ACD 12 call queue. When this queueis above a threshold, the Contact Server 28 will not process call-backrequests in a call-back request queue. When the ACD 12 call queue fallsbelow a threshold, the Contact Server 28 begins processing call-backrequests in the call-back request queue.

The Contact Server 28 can be equipped with a call-back cutoff button, aspart of a user interface. This allows all call-back request processingto be manually shutoff, for example, if the call center is beingoverloaded with inbound calls.

The Contact Server 28 can use skills designators other than customeridentifiers. This is useful to implement call-back services on Web pagesthat do not require user authentication and therefore do not have userprofiles. The URL of the Web page (from which a call-back request isplaced) can be matched to a skills designator to identify the agentstrained to service that Web page. The IP address of the customer placingthe call-back request can also be matched to a skills designator,assuming that IP address was previously registered with the ContactServer 28. Finally, information entered by the customer in the call-backdialog box can be used as a skills designator.

FIG. 11 is a figurative illustration of the network architecture of acompany call center according to FIG. 1 which utilizes multiplealternate TCP/IP protocols for communication between the agent and thecustomer. This Figure illustrates how alternate methods of call-back maybe used by customers and agents. While one agent 14 communicates withCustomer B 42 by the ACD phone switch 12, another agent 14 communicateswith Customer A by both the ACD phone switch 12 and the Internet Webbrowser.

Additionally, at the same time, a manager station 60 may monitor theinterchange of data and activities between a client and an agent. Suchmonitoring system is enabled by the Contact Server API 200 which tracksall the agent and client states.

1. In a user support system for providing support to a user accessing aweb site, a method comprising: receiving, via at least one of one ormore of devices in the user support system, information associated withthe user, the information comprising at least one of the user's name,the user's telephone number, an Internet protocol address associatedwith the user, or a uniform resource locator representing a web page;accessing, via at least one of the one or more of devices in the usersupport system, a web page based on the received information;establishing, via at least one of the one or more of devices in the usersupport system, a communications link with the user; and passing, via atleast one of the one or more of devices in the user support system,events performed on the user support system to the user via thecommunications link to enable the user to view a same web page as thatbeing displayed by the user support system.
 2. The method of claim 1,wherein the events comprise actions performed by a user support partyvia the user support system.
 3. The method of claim 1 furthercomprising: identifying the user support party from a plurality of usersupport parties based on the information associated with the user. 4.The method of claim 3, where the information associated with the userfurther includes a selection of one or more of a plurality of user sportservice categories, and where identifying the user support party isbased on the selection of the one or more of the plurality user sportservice categories.
 5. The method of claim 1, where the informationassociated with the user includes the uniform resource locatorrepresenting the web page, and where the web page is used by the user torequest the support.
 6. A system for providing support to a useraccessing a web sit; comprising: at least one processing device to:receive information associated with the user, the informationidentifying the web site that the user was accessing when a request foruser support was made, access the web site based on the receivedinformation, and establish a communications link with the user, whereinthe at least one processing device includes a display device, the atleast one processing device being further configured to: pass events tothe user via the communications link to enable the user to view a sameweb page as that being displayed by the display device.
 7. The system ofclaim 3, wherein the events comprise; actions performed by a usersupport party via the at least one processing device.
 8. The system ofclaim 6, where the at least one processing device is further to:identify the user support party from a plurality of user support partiesbased on the information associated with the user.
 9. The system ofclaim 8, where the information associated with the user further includesa selection of one or more of a plurality of user sport servicecategories, and where identifying the user support party is based on theselection of the one or more of the plurality user sport servicecategories.
 10. The system of claim 6, where the information associatedwith the user includes a uniform resource locator associated with theweb site.
 11. The system of claim 6, where the communications linkincludes a transmission control protocol/internet protocol link.